IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Release 5 and Release 6). IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (UEs) or between UEs and application servers (ASs). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically the IMS architecture and its internal and external interfaces. Call/Session Control Functions (CSCFs) operate as SIP entities within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers in the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling, and charging for, user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF, if an S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. It is noted that S-CSCF allocation is also carried for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF. When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Every IMS user possesses one or more Private User Identities. A Private User Identity is assigned by the home network operator and is used by the IMS, for example for registration, authorisation, administration, and accounting purposes. This identity takes the form of a Network Access Identifier (NAI) as defined in RFC 2486. It is possible for a representation of the International Mobile Subscriber Identity (IMSI) to be contained within the NAI for the private identity. 3GPP TS 23.228 specifies the following properties of the Private User Identity:                The Private User Identity is not used for routing of SIP messages.        The Private User Identity shall be contained in all Registration requests, (including Re-registration and De-registration requests) passed from the UE to the home network.        An IP multimedia Services Identity Module (ISIM) application shall securely store one Private User Identity. It shall not be possible for the UE to modify the Private User Identity information stored on the ISIM application.        The Private User Identity is a unique global identity defined by the Home Network Operator, which may be used within the home network to identify the user's subscription (e.g. IM service capability) from a network perspective. The Private User Identity identifies the subscription, not the user.        The Private User Identity shall be permanently allocated to a user's subscription (it is not a dynamic identity), and is valid for the duration of the user's subscription with the home network.        The Private User Identity is used to identify the user's information (for example authentication information) stored within the HSS (for use for example during Registration).        The Private User Identity may be present in charging records based on operator policies.        The Private User Identity is authenticated only during registration of the user, (including re-registration and de-registration).        The HSS needs to store the Private User Identity.        The S-CSCF needs to obtain and store the Private User Identity upon registration and unregistered termination.        
In addition to a Private User Identity, every IMS user shall have one or more IMS Public User Identities (IMPUs). The IMPUs are used by any user to request communications to other users. A user might for example include an IMPU (but not a Private User Identity) on a business card. 3GPP TS 23.228 specifies the following properties of the IMPU:                Both telecom numbering and Internet naming schemes can be used to address users depending on the IMPUs that the users have.        The IMPU(s) shall take the form of a SIP URI (as defined in RFC 3261 and RFC 2396 or the “tel:”-URI format defined in RFC 3966.        An ISIM application shall securely store at least one IMPU (it shall not be possible for the UE to modify the IMPU), but it is not required that all additional IMPUs be stored on the ISIM application.        An IMPU shall be registered either explicitly or implicitly before the identity can be used to originate IMS sessions and IMS session unrelated procedures.        An IMPU shall be registered either explicitly or implicitly before terminating IMS sessions and terminating IMS session unrelated procedures can be delivered to the UE of the user that the IMPU belongs to.        It shall be possible to register globally (i.e. through one single UE request) a user that has more than one IMPU via a mechanism within the IMS (e.g. by using an Implicit Registration Set). This shall not preclude the user from registering individually some of his/her IMPUs if needed.        IMPUs are not authenticated by the network during registration.        IMPUs may be used to identify the user's information within the HSS (for example during mobile terminated session set-up).        IMPUs may be used by ASs within the IMS to identify service configuration data to be applied to a user.        
FIG. 2 illustrates schematically example relationships between a user (IMS) subscription and the Public and Private User Identities. In the example shown, a subscriber has two Private User Identities, with both being associated with two Public User Identities (one of the Public User Identities, Public User Identities-2, being associated with both Private User Identities). A Service Profile is associated with each Public User Identities, this profile specifying service data for the associated Public User Identities. A Service Profile is created or modified when an application server is provisioned for a user at the Home Subscriber Server. Each Service Profile comprises one or more initial Filter Criteria (iFC) which are used to trigger the provision, or restriction, of IMS services. The differences between services offered by Service Profile-1 and Service Profile-2 are operator specific, but may involve different application servers (ASs), and even different charging/rating schemes.
In the example, Public User Identity-1 is associated with a Service Profile-1, whilst Public User Identity-2 and Public User Identity-3 are associated with Service Profile-2. In a typical scenario, the Public User Identity-1 might be an identity that the user gives to friends and family, e.g. “Big_Joe@priv.operator.com”, whilst Public User Identity-2 and Public User Identity-3 might be identities that the user gives to business contacts, e.g. “+46111222333@operator.com” and “joe.black@operator.com”.
Within the IMS service network, application servers (ASs) are provided for implementing IMS service functionality. For any given UE, one or more ASs may be associated with that terminal. FIG. 3a illustrates the IMS Service Control (ISC) interface between an AS and an S-CSCF, as well as other interfaces within the IMS. Although the AS in FIG. 3a is shown as having only a single interface to an S-CSCF, it will be appreciated that in practice the ISC interface will extend across a communication network to which many (or all) of the CSCF servers of a given operator's network are connected, allowing an AS to communicate with all of these CSCFs. [Other entities illustrated in FIG. 3a will be well known to those of skill in the art.]
A further interface (Ut) exists between the AS and the UE (TS23.002) as illustrated in FIG. 3b. The Ut interface enables the user to manage information related to his or her services, e.g. creation and assignment of Public Service Identities, management of authorisation policies that are used for example by “presence” services, conference, policy management, etc.